Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@lyne7-sc, thanks for the fix! The overall approach is sound: materialize __paimon_file_path/__paimon_bucket as per-file constants via partitionSchema, and fall back to Spark for unsupported metadata columns. The functional Test Paimon 1.2 CI job (which runs the new integration tests) is green.

@lyne7-sc, thanks for updates. The approach — reusing the partition-constant mechanism rather than reading these from Parquet/ORC — is clean. I found two correctness issues (verified against the decompiled Paimon 1.2.0 sources) plus a couple of value-fidelity edge cases and test-coverage gaps; inline comments below. Recommend addressing the two confirmed bugs (__paimon_file_path encoding, and the partition-key/metadata name collision) before merge.

Minor (not blocking): in toPartitionValueTemplate, SQLConf.get.resolver and indexByName = partitionKeys.zipWithIndex.toMap are split-invariant but rebuilt per split; and partitionKeys() is fetched twice (a Set at L131 and a Seq at L175). Worth hoisting into computePlan. Also consider whether file_path could be materialized on the executor (as NativeIcebergTableScanExec.metadataPartitionValues does) instead of baked into a per-file InternalRow on the driver.

LGTM. The native Paimon V2 scan correctly handles __paimon_file_path and __paimon_bucket, falls back for unsupported metadata columns, and properly distinguishes physical/partition columns that collide with metadata names. The test coverage (multi-file splits, non-zero buckets, name collisions, partitioned tables, special-character partition values) is thorough.

One thing I verified closely: the __paimon_file_path value is built with new Path(rawFilePath).toUri.toString. This matches Paimon 1.2.0, whose PaimonRecordReaderIterator materializes the column via filePath().toUri().toString() (the percent-escaped form) — confirmed against the paimon-spark-3.x:1.2.0 artifact. So results agree with vanilla Paimon, including the '50%' partition case. (Note for the future: newer Paimon switched this to Path.toString()/unescaped, so if Auron ever bumps the Paimon dependency this rendering will need to follow.)

A few optional, non-blocking nits:

• PaimonScanSupport.scala — in toPartitionValueTemplate, the else if (isFilePathMetadataColumn(field.name)) null branch returns the same null as the trailing else (dead) and, unlike isPartitionValueField / filePathMetadataIndex, omits the !isPhysicalColumn guard. Safe today only because a physical column reaches partitionSchema solely as a real partition key; consider dropping the branch or adding the guard for consistency.
• metadataFilePath = new Path(...).toUri.toString is computed for every data file even when no __paimon_file_path column is projected (filePathMetadataIndex < 0) and then discarded — could be guarded behind filePathMetadataIndex >= 0.
• containsName / isFilePathMetadataColumn / isBucketMetadataColumn re-fetch SQLConf.get.resolver per call inside the per-field/per-file loop, though computePlan already binds resolver.
• In isPaimonMetadataColumn, the containsName(PaimonMetadataColumns, name) clause is subsumed by the startsWith("__paimon_") prefix check, so the PaimonMetadataColumns set is redundant.
• dataFile.externalPath().orElse(s"...") eagerly builds the fallback string even when externalPath() is present; orElseGet(...) would defer it.

None of these block the change.